This invention relates to the field of information retrieval and bi-directional messaging and more particularly to the integration of heterogenous computer systems into an enterprise wide message driven client-server system which simplifies network connections and facilitates business process re-engineering.
CORBA is a distributed object system that is defined under the Common Object Request Broker Architecture (CORBA) specification produced by OMG. Distributed object systems may be in the context of an Object Request Broker (ORB) implemented under the CORBA specification from the OMG. Revision 2.0, Revision 2.1, Revision 2.2 and Revision 2.3, all of which are incorporated herein by reference in their entirety. For purposes of this disclosure, program compliant with CORBA Revision 2.3, 2.2, and 2.1 by definition will be viewed as compliant with CORBA Revision 2.0. Unless otherwise specified, a generic reference to CORBA will be presumed to be OMG""s CORBA Services Revision 2.0 and a generic reference to CORBA-complaint or to a CORBA platform or program or system will be viewed as compliant with CORBA Services Revision 2.0.
Mercury is a CORBA based communication system that facilitates bi-directional messaging between any CORBA platform and a server platform in a peer-to-peer manner. Client applications (Java, C++ and Smalltalk applications that run on NT and Sun) can communicate with server applications (DB2, COBOL, Natural) through Mercury""s messaging mechanism. Mercury is a specific embodiment of an ASCII-based text messaging system for facilitating communication between CORBA and non-CORBA platforms. While the following discussion primarily focuses on Mercury specifically, the same principles could equally be applied to any ASCII-based text messaging system serving similar functions.
COBOL applications deal with data using a data structure referred to as a copybook. A copybook is a text file that defines a data structure used by the server application. Each copybook consists of a field name, a data type, and field length. Natural applications deal with data using xe2x80x9cpdlxe2x80x9d or xe2x80x9cpdaxe2x80x9d files which, for purposes of this invention, shall likewise be referred to as copybooks. While not identical in structure to Cobol copybooks, these Natural storage units may be similarly handled for conversion purposes. While the foregoing discussion will primarily be addressed in terms of COBOL copybooks, it is likewise applicable to pda or pdl files for Natural applications. For the purposes of this disclosure the use of the term copybook, in the absence of specifying COBOL copybook, shall be defined to include pda or pdl files for Natural applications. Similarly they may be generally or collectively referred to as data structures.
Client applications that wish to communicate with server applications through Mercury must obtain the copybook of the desired server application.
Mercury has a parameter called applicationMessage that is used for passing data between client and server applications. The applicationMesaage is an ASCII string that contains data in a sequence of ASCII characters. The applicationMessage data reflects the copybook""s data structure.
Following is a simple copybook for a COBOL application:
01 LNP-DATA-RECORD1.
The server application uses the offset from the beginning of the copybook to determine the value of each field.
Here is the applicationMessage layout for the above copybook. 
Client applications can define message sending to Mercury by mapping each field of the copybook to an array of characters. This represents direct mapping of the copybooks which is carried out by each of the individual client applications. There are some major disadvantages by doing direct mapping:
1. Copybooks usually contain multiple fields, sometime up to hundreds and usually has some complicated inner structure (e.g. nested structures (referred to in COBOL as occurs), arrays, and the like). Server applications treat the data strictly by their offsets. If any field""s offset is miscalculated, then every field could potentially be invalid.
2. Copybook fields have various data types (i.e. character, integer, float etc.), that need to be converted into different data types in ASCII.
3. Client applications area expected to be simple, flexible, and easily updated if a copybook is changed.
The present invention includes a method for generating computer files based on user input which facilitate communication between a client application and a copybook text file. The method includes reading in a copybook text file selected by the user, wherein the copybook text file comprises a set of fields with corresponding values for each field, and converting the copybook structure into an internal data representation. The present invention also provides for accepting user input defining output options and accepting user input defining at least one interface function. The present invention generates an IDL file from the internal data representation which represents the copybook as an IDL struct, with each field of the copybook as a member of the struct, and which incorporates the interface function defined by the user. The generated IDL file enables communication with CORBA-compliant systems. The present invention also generates an application server class implementing the interface functions defined by the user. Finally, the present invention generates a copybook interface class, which is used by the client application through the application server class to set and to get the copybook values through the IDL file.
The currently preferred embodiment of the present invention communicates with the copybook text file at least in part through communication with an ASCII-based text messaging system. This alternative embodiment generates a copybook converter class which converts the value of a field of the copybook as represented in the IDL file into a character array which may be transmitted. The copybook converter class also does the reverse, converting a character array into the value of a field of the copybook as represented in the IDL file. In this alternative embodiment, the application server class additionally implements functions for communicating with the ASCII-based text messaging system, wherein the ASCII-based text messaging system enables communication with non-CORBA complaint systems.
The result of the above method is a software system and method for using the system to facilitate communication. The present invention may thus also be described as a software system for facilitating communication between a client application and server application having a copybook text file wherein the copybook text file comprises a set of fields with corresponding values for each field. The system includes an IDL file which represents the copybook as an IDL struct, with each field of the copybook as a member of the struct, and which incorporates at least one interface function defined by the user, wherein the IDL file enables communication with CORBA-compliant systems. The system includes an application server class implementing at least one interface function defined by the user. And the system includes a copybook interface class, which is used by the client application through the application server class to set and to get the copybook values through the IDL file. In the current preferred embodiment the system also includes an ASCII-based test messaging system, wherein the ASCII-based text messaging system enables communication with non-CORBA-compliant systems. The current preferred embodiment also includes a copybook converter class which converts the value of a field of the copybook as represented in the IDL file into a character array with may be transmitted and which converts a character array into the value of a field of the copybook as represented in the IDL file. In this current preferred embodiment the application server class also implements functions for communicating with the ASCII-based test messaging system.
A preferred embodiment of the present invention also provides a method for facilitating communication specifically including exchanging a request message and a response message between a client application and a server application having a copybook text file. This method works as follows. The client application is used to instantiate at least one Copybook Interface class object to build a request message. The Copybook Interface class object is used to marshall the request message as an IIOP message using an IDL Data Struct. The client application is used to instantiate an Application Server class object to handle the request message. The Application Server class object is used to receives the IIOP request message from the Copybook Interface class object and then to communicate the request message to the destination server application in a form compatible with the syntax and protocol of the server application copybook text file. The Application Server class object is then used to receive a response message from the destination server application and to return the response message in the form of an IIOP message. Finally, the Copybook Interface class object is used to receive the IIOP response message and to unmarshall the IIOP response message using the IDL Data Struct and return the response to the client application.